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REMARKS 

I. General 

Claims 1-37 were pending in the present application, and all of the pending claims are 
rejected in the current Office Action (mailed July 27, 2006). The outstanding issues raised in the 
current Office Action are: 

Claims 1-37 are rejected under 35 U.S.C. § 103(a) as being unpatentable over 
U.S. Patent No. 6,775,692 issued to Albert et al (hereinafter "Albert") in view of U.S. Patent No. 
5,774,660 issued to Brendel et al. (hereinafter "Brendel"). 

In response, Applicant respectfully traverses the outstanding claim rejections, and 
requests reconsideration and withdrawal thereof in light of the remarks presented herein. 

II. Rejections Under 35 U.S.C. §103(a) over Albert in view of Brendel 

All of claims 1-37 were previously rejected in a Final Office Action mailed April 20, 
2005 as being anticipated under 35 U.S.C. § 102(e) by Albert. In response, Applicant appealed 
the rejection to the Board and submitted an Appeal Brief presenting arguments regarding why 
the claims are not anticipated by Albert. In response to the Appeal Brief, the Examiner has 
reopened prosecution and now rejects the claims as being unpatentable over Albert in view of 
Brendel. Applicant respectfully submits that Brendel does not cure the deficiencies of Albert for 
the reasons discussed below. In particular, Brendel is discussed in the Background section of the 
present application {see page 5, line 25 - page 6, line 12 of the present application) and is noted 
as disclosing an inefficient mechanism for transferring TCP states that requires use of a 
proprietary protocol that is known only to the application level, which embodiments of the 
present invention overcome. Thus, for the reasons discussed further below, the combination of 
Brendel with Albert fails to render the claims unpatentable. As such, Applicant respectfully 
requests that the rejections be withdrawn and this application be passed to allowance. 
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To establish a prima facie case of obviousness, three basic criteria must be met. See 
M.P.E.P. § 2143. First, there must be some suggestion or motivation, either in the references 
themselves or in the knowledge generally available to one of ordinary skill in the art, to modify 
the reference or to combine reference teachings. Second, there must be a reasonable expectation 
of success. Finally, the applied references must teach or suggest all the claim limitations. 
Without conceding any other criteria, the applied references fail to teach or suggest all elements 
of the claims. 

Independent Claim 1 

Independent claim 1 recites: 

In a communication network, a method of TCP state migration comprising 
the steps of: 

a) establishing a TCP/IP communication session between a client 
computer and a first server computer, said first server computer part of a plurality 
of server computers forming a web cluster containing information, said 
communication session established for the transfer of data contained within said 
information; 

b) handing off said communication session to a selected server 
computer from said first server computer over a persistent control chan nel using 
TCP handoff modules that are dynamically loadable within TCP/IP stacks in 
operating systems located at both said first server computer and said selected 
server computer, that implement a TCP handoff protocol that works within kernel 
levels of an existing TCP/IP protocol : and 

c) migrating a first TCP state of said first server computer to said 
selected server computer, and a second TCP state of said selected server computer 
to said first server computer over said control channel. (Emphasis added). 

The combination of Albert and Brendel fails to teach or suggest all elements of 
independent claim 1. For the reasons discussed further in the Appeal Brief of January 5, 2006, 
Albert fails to disclose at least: 

A) TCP handoff modules that are dynamically loadable within TCP/IP stacks in operating 
systems located at both said first server computer and said selected server computer; 

B) handing off said communication session; and 

C) a persistent control channel. 
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The current Office Action appears to concede that Albert fails to teach or suggest "b) 
handing off said communication session to a selected server computer from said first server 
computer over a persistent control channel using TCP handoff modules that are dynamically 
loadable within TCP/IP stacks in operating systems located at both said first server computer and 
said selected server computer, that implement a TCP handoff protocol that works within kernel 
levels of an existing TCP/IP protocol", see page 3 of the Office Action. However, the Office 
Action asserts that Brendel discloses this element of the claim. Applicant respectfully disagrees, 
as discussed below. 

The present application briefly discusses Brendel at page 5, line 25 - page 6, line 12 as 
follows: 

Previously, various mechanisms for transferring TCP states were 
implemented, including using a separate proprietary protocol at the application 
layer of an operating system. For example, in the Brendel et al. patent (U.S. 
5,774,660), incoming packets to the front-end node have their protocol changed 
from TCP/IP protocol to a non-TCP/IP standard that is only understood by the 
proprietary protocol located at the application layer. Later, the packets are 
changed back to the TCP/IP protocol for transmission to the back-end web server. 
Thus, the Brendel et al. patent reduces processing efficiency by switching back 
and forth between the user-level and kernel level layers of the operating system. 

Thus, a need exists for a more efficient design for implementing a 
mechanism for transferring TCP states in a web server cluster. 

Thus, the present application expressly recognized that Brendel fails to provide TCP 
handoff modules within TCP/IP stacks in operating systems that implement a TCP handoff 
protocol that works within kernel levels of an existing TCP/IP protocol. Instead, Brendel 
requires that incoming packets be changed into a proprietary protocol that is understood only at 
the application layer. For instance, Brendel explains at col. 13, lines 40-46 thereof: 

Modified TCP/IP stack 82 contains the standard TCP and IP modules with 
some modifications explained later. One modification is that incoming packets 
from the Internet have their protocol changed from TCP to a proprietary "IXP" 
protocol. Since this IXP protocol is unknown to the standard TCP and IP layers, 
it is sent directly up to application layer 80 containing the load balancer. 
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Thus, Brendel appears to disclose a system in which the TCP/IP stack of an operating 
system is modified so as to change incoming packets from the TCP protocol to a proprietary 
protocol that is understood only at the application layer, rather than implementing TCP handoff 
modules within the TCP/IP stack to implement a TCP handoff protocol as recited by claim 1 . 

Thus, for at least the above reasons, the combination of Albert and Brendel fails to teach 
or suggest all elements of claim 1 . As such, the rejection of claim 1 should be withdrawn, and 
claim 1 should be passed to allowance. 

Independent Claim 1 1 

Independent claim 1 1 recites: 

In a communication network, a method of TCP state migration comprising 
the steps of: 

a) establishing a TCP/IP communication session between a client 
computer and a first server computer, said first server computer part of a plurality 
of server computers forming a web cluster containing information, said 
communication session established for the transfer of data contained within said 
information; 

b) monitoring traffic associated with establishing said TCP/IP 
communication session to understand a first initial TCP state of said first server 
computer associated with said TCP/IP communication session, at a first bottom- 
TCP (BTCP) module at said first server computer; 

c) receiving a web request associated with said TCP/IP 
communication session at said first BTCP module at said first server computer; 

d) examining content of said web request; 

e) determining which of said plurality of server computers, a selected 
server computer, can best process said web request, based on said content; 

f) handing off said communication session to said selected server 
computer from said first server computer over a persistent control channel, if said 
selected server computer is not said first server computer; 

g) monitoring traffic associated with handing off said TCP/IP 
communication session to understand a second initial TCP state of said selected 
server computer associated with said TCP/IP communication session, at a second 
BTCP module at said selected server computer; 

h) migrating said first initial TCP state to said selected server 
computer over said control channel, such that said second BTCP module can 
calculate a first TCP state for said first server computer in said TCP/IP 
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communication session; 

i) sending a second initial TCP state of said selected server computer 
to said first BTCP module, such that said first BTCP module can calculate a 
second TCP state for said selected server computer in said TCP/IP 
communication session; 

j) forwarding data packets received at said first BTCP module from 
said client to said selected server computer, by changing said data packets to 
reflect said second TCP state and a second IP address of said selected server 
computer; 

k) sending response packets from said selected server computer 
directly to said client computer by changing said response packets to reflect said 
first TCP state and a first IP address of said first server computer; and 

1) terminating said TCP/IP communication session at said first server 
computer when said TCP/IP communication session is closed. 

The combination of Albert and Brendel fails to teach or suggest all elements of 
independent claim 1 1. As discussed further in the Appeal Brief of January 5, 2006, Albert fails 
to disclose at least: 

A) a first bottom-TCP (BTCP) module at said first server computer, and a second BTCP 
module at said selected server computer; 

B) examining content of said web request and determining which of said plurality of 
server computers, a selected server computer, can best process said web request, based on said 
content; 

C) sending response packets from said selected server computer directly to said client 
computer; 

D) handing off said communication session; and 

E) a persistent control channel. 

Further, Brendel fails to teach or suggest at least a first bottom-TCP (BTCP) module at 
said first server computer, and a second BTCP module at said selected server computer, as 
recited by claim 1 1 . For instance, as discussed above with claim 1, Brendel does not teach or 
suggest any such BTCP modules, but instead appears to disclose a modified TCP/IP stack that 
changes an incoming packet's protocol to a proprietary protocol that is unknown to the TCP/IP 
stack for handling at the application level. 
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Thus, for at least the above reasons, the combination of Albert and Brendel fails to teach 
or suggest all elements of claim 1 1 . As such, the rejection of claim 1 1 should be withdrawn, and 
claim 1 1 should be passed to allowance. 

Independent Claim 26 

Independent claim 26 recites: 

A server computer comprising: 

an upper TCP (UTCP) module located above a TCP module in an 
operating system of said server computer; 

a bottom TCP (BTCP) module located below said TCP module, said 
UTCP, TCP, and BTCP modules implementing a method of handing off a 
communication session between a first node and second node in a cluster network 
that works within the kernel level of an existing TCP/IP protocol, by migrating 
TCP states associated with said first and second nodes. 

The combination of Albert and Brendel fails to teach or suggest all elements of 
independent claim 26. As discussed further in the Appeal Brief of January 5, 2006, Albert fails 
to disclose the recited UTCP and BTCP modules. 

Further, Brendel fails to teach or suggest the UTCP and BTCP modules. For example, 
Brendel does not teach or suggest UTCP, TCP, and BTCP modules that implement a method of 
handing off a communication session between a first node and second node in a cluster network 
that works within the kernel level of an existing TCP/IP protocol, as recited by claim 26. For 
instance, as discussed above with claim 1, Brendel does not teach or suggest any such modules 
that implement handing off a communication session that works within the kernel level of an 
existing TCP/IP protocol, but instead appears to disclose a modified TCP/IP stack that changes 
an incoming packet's protocol to a proprietary protocol that is unknown to the TCP/IP stack for 
handling at the application level. 

Thus, for at least the above reasons, the combination of Albert and Brendel fails to teach 
or suggest all elements of claim 26. As such, the rejection of claim 26 should be withdrawn, and 
claim 26 should be passed to allowance. 
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Dependent Claims 

In view of the above, Applicant respectfully submits that independent claims 1,11, and 
26 are not unpatentable under 35 U.S.C. § 103 over Albert in view of Brendel. Further, each of 
dependent claims 2-10, 12-25, and 27-37 depend either directly or indirectly from one of 
independent claims 1, 1 1, and 26, and thus inherit all limitations of the respective independent 
claim from which they depend. It is respectfully submitted that dependent claims 2-10, 12-25, 
and 27-37 are allowable not only because of their dependency from their respective independent 
claims for the reasons discussed above, but also in view of their novel claim features (which both 
narrow the scope of the particular claims and compel a broader interpretation of the respective 
base claim from which they depend). 

III. Conclusion 

In view of the above, Applicant believes the pending application is in condition for 
allowance. Applicant believes no fee is due with this response. However, if a fee is due, please 
charge our Deposit Account No. 08-2025, under Order No. 10010812-1 from which the 
undersigned is authorized to draw. 



Respectfully submitted, 




Attorney/Agent for Applicant(s) 
Reg. No. 44,034 
Date: October 25, 2006 
Telephone No. (214) 855-8007 
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